In Protocol Independent Multicast-Sparse Mode (PIM-SM), a router with directly connected hosts is referred to as a Last-Hop-Router (LHR). When one of the hosts attached to the LHR wants to receive multicast traffic, the LHR sends a PIM-JOIN message towards the network's Rendezvous Point router (RP). The RP then connects the source of the multicast flow to the LHR.
Multicast traffic initially arrives at the LHR via the Rendezvous Point Tree (RPT), which is a network path that connects the RP to the LHR. Once multicast traffic arrives at the LHR via the RPT, the LHR has the option of requesting that the multicast traffic arrives directly from the source of the traffic via a Shortest Path Tree (SPT). The main reason for the LHR to request that the multicast traffic arrives via the SPT is to reduce latency (typically the path via the RPT is longer, and therefore the delay is usually longer). Once the LHR starts receiving the multicast traffic via the SPT, it sends a notification to the RP, informing it that the LHR no longer needs to receive that particular multicast flow via the RPT.
This mechanism of initially receiving a multicast flow via the RPT, then requesting that the flow arrives via the SPT, and finally informing the RP that it doesn't need to forward the flow anymore, is usually referred to as the “RPT-to-SPT switchover process”.
One mechanism commonly used by the LHR to decide when to initiate the switch to the SPT is to monitor the packet flow rate of the multicast packets received via the RPT. If the rate surpasses a threshold established by the user, then the LHR initiates the switch to the SPT.
Monitoring the packet flow rate can be a resource-intensive operation. A software process performing this task can become a bottleneck within the LHR, especially if the software process has to frequently poll and calculate the packet flow rates for multiple multicast flows.
Accordingly, what is needed is a method for efficiently monitoring the packet flow rates of multiple multicast packet flows received via the RPT without consuming significant resources of the network node. What is also needed is a network node that can efficiently monitor the packet flow rates of multiple multicast packet flows received via the RPT.